\documentclass[10pt,english,a4paper]{article}

\usepackage[utf8]{inputenc}
\usepackage{babel,graphicx}
\usepackage{fancybox}
\usepackage{graphicx}
\usepackage[table]{xcolor}
\usepackage{color}


\usepackage{times}
\usepackage{url}

\usepackage{float}

\floatstyle{ruled}
\newfloat{program}{thb}{lop}
\floatname{program}{Code example}



\title{Dynamic Presentation Generator \\ Part III: Security Patterns}
\author{Lars Hopland Nestås - lma029@student.uib.no \\ Tobias Rusås Olsen -
tol060@student.uib.no \\Group 7}
\date{\today}

\tolerance = 5000

\hbadness = \tolerance
\pretolerance = 2000
% mange lange sammensatte ord.


\begin{document}

\begin{titlepage}
\maketitle
\thispagestyle{empty}
\begin{figure}[htb]
\centering

\end{figure}

\begin{abstract}
This paper includes a risk evaluation of the Dynamic Presentation Generator
(DPG), some solutions to the vulnerabilites found in part 2, and
some ideas to new security patterns which could be feasable to DPG.
\end{abstract}

\end{titlepage}

\pagenumbering{arabic}

\newpage

\section{Introduction}
During the work with part II, Static analysis, we discovered several security related issues in the DPG system. We can divide the vulnerabilities into two categories; vulnerabilities caused by bad coding, vulnerabilities caused by bad system design.
The main goal is reach a level of “just enough security”.

In the first part of this report we will use some of the “Enterprise Security and Risk Management” patterns for defining and identifying assets, threats and vulnerability, and risk determination.  We will then try to use the “pattern approach” to solve some of the security related problems we discovered in “part II - Static analysis”.

\section{Enterprise Security and Risk Management}
While working with the patterns leading up to Risk determination, we learned
that it is quite hard to do asset valuation, threat assessment, risk
determination and etc., only describing the system in generic terms.  In the
document “Systemdesign for DPG 2.0”\cite{design} it is written:
\begin{quote}\textit{The purpose of the system is to offer a content management system that is generic enough to manage content of any kind of structure […]}
\end{quote}
In the section "Design goals" in the same document we find some of the points
interesting:
\begin{itemize}
  \item Maintenance: We want DPG 2.0 to have a design such that maintenance is as easy as possible. The system should be easy to extend.
  \item Security: DPG must be designed in a way that it protects its content and other data against unauthorized access.
  \item Lightweight: Installation and deployment should be quick and easy, and the system should not use infrastructure that prevent this goal.
  \item Portability: Even though DPG 2.0 is designed for use with Tomcat, it should be arranged in a way that system also could be used on other J2EE-servers/containers.
\end{itemize}

The result of a risk management process is very dependent on the context the system is put into. Let’s for example say that a DPG presentation is used to present lecture notes and the schedule for a programming course. Then there is not a lot of sensitive data in a presentation. On the other hand, if a medical research team uses DPG to present research results and drafts to paper etc., then we would probably rate the value of the presentations content much higher. If “not yet published” research result are leaked this could of course have greater consequences than a compromised lecture schedule.

We have therefore decided to use a fictive (but as we see it a realistic)case in this risk management process.
\paragraph*{Case: INF101 online course} The programming course INF101 “Videregående programmering i Java” is using DPG for it's onlie course. The presentations administrator is the lecturer, and several teaching assistants operate as publishers. The students are readers.  On the page lecture notes, course schedule, information about lectures, exercises, exam, syllabus etc. are presented. Solutions to compulsory exercises are also uploaded to the site, and made available after the deadline for delivery.

\subsection{Security needs identification for Enterprise Assets}
\begin{quote}\textit{This is the root pattern for all enterprise security conserns. It helps resolve the issue of wheter security is really needed and, if it is what properties of security should be applied for a particular enterprise. Security properties considered include confidentiality, integrity, availability and accountability.}
\begin{flushright}
\textit{--- Chapter 6.1, page 89} % --- gir en tankestrek.
\end{flushright}
\end{quote}

The activities in this pattern can be divided into five steps:
\begin{enumerate}
  \item Identify the assets
  \item Identify business factors
  \item Determine which assets relate to which business factors.
  \item Identify what types of security may be needed
  \item Determine for each asset type which types of security are needed.
\end{enumerate}

We have gone through each of this five steps,

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{table1.png}
\caption{Asset types with related security properties and business factors}
\label{fig:table1}
\end{figure}


\paragraph*{Course resources}
This asset contains information about the course, lecture notes, illustrations,
media files and other file resources.  It is important that all information is
available for the students at any time since this is an online course.  The
presentation is the main information source for the students. So it is very
important that this asset has a high degree of integrity.  Because of the
course fee the students must pay, the content should only be available to the
students. The presentation, and its content, must therefore have a high degree
of confidentiality. If some of these security properties fail, it would have an
impact on the relations between the university and the students; it would
damage the university’s reputation and also the DPG developer’s reputation.  If
the content is made available to everyone, not only the students which have
paid the course fee, the economic foundation for holding this online course
would probably be reduced.

\paragraph*{Solutions to compulsory exercises}
Every student must solve several compulsory exercises during the course. The
result on every exercise will be a part of the student’s final grade. The
student assistants have uploaded solutions to every exercise a head of the
course, and the solutions are made available after the delivery deadline of
every exercise.

\paragraph*{Presentation editor and resource management}
The presentation editor and the resource management tool are important assets
for the administrator and the publishers. To keep progress in the course, new
content must be published and old content must be maintained. These assets
should have a high grade of confidentiality to keep the integrity of content
made available through the presentation viewer. Accountability should also be
considered, to keep track of misuse of obtained administrator and publisher
rights.

\paragraph*{Lobby}
User administration and user data is handled by the Webucator system. Lobby is
the name of the DPG subsystem which operates the authentication process, and
list up available presentations for the users. This asset must therefore have a
high grade of confidentiality to ensure that the users get correct access
rights. User credentials must be handled in a proper way. The service must have
a high grade of availability. Accountability is also very essential for this
asset to keep people responsible of misuse.

\paragraph*{Presentation configuration files}
The data in this asset defines “the look and feel” of a presentation in the
Presentation Viewer. As we pointed out in part II the tools that let an
administrator configure presentation patterns, specifications, page templates,
style sheets etc. is a very powerful tool. Any unintended changes here could
lead to a corrupt presentation. It is quite critical for the online course that
these files are correct configured. The configuration files must either contain
any malicious code that lead to unintended behaviour that is hidden for the
users of a presentation.  Accountability is also very essential for this asset.
It is then possible to detect unwanted changes and keep people responsible of misuse.

\paragraph*{DPG system files}
These files should only be available for system administrators.  Corrupt system
files could lead to loss of data, time and have a huge impact on the business.
It could be very costly to do a “reinstallation” of the system that is in
production.


\subsection{Asset valuation}
\begin{quote}\textit{Asset valuation helps you to determine the overall
importance an enterprise places on the assets it owns and controls. Loss or
compromice of such assets may result in anything from hard costs, such as fines
and fees, to soft costs due to loss of market share and consumer confidence.}
\begin{flushright}
\textit{--- Chapter 6.2, page 103} % --- gir en tankestrek.
\end{flushright}
\end{quote}

It is pointed out that the ability to define an asset's value is a key component
of any risk assessment. Since DPG can be used in many different contexts, the
value of an asset is heavily influenced by its context. For each asset a
security value, a financial value and impact to business should be determined.
The results of these valuation determines the overall value.

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{table2.png}
\caption{Asset types with values}
\label{fig:table2}
\end{figure}

\paragraph*{Course resources}
The content in a presentation is of course a very valuable asset. But in our
case, the online course, compromise of this data would not cause any leak of
sensitive or critical information. If the rest of the DPG system is working
properly reconstructing or replacing of data could be done easily.  On the
other hand, this asset has a major impact on concept of doing online teaching.
So it scores higher on the “Business impact”.

\paragraph*{Solutions to compulsory exercises}
This asset has much in common with the rest of the course resources. But it is
rated higher on security value because compromising of this asset cold lead to
cheating among the student. The students could then end up with better grades
then they deserve. If this gets public it could damage the relationship between
the students and the university, and damage the university’s reputation.

\paragraph*{Presentation editor and resource management}

If the presentation editor is broken, the system will not be able to update any
information which can stop the flow of information from presenter til user.
The availability of this feature is not as important as the course resources,
therefore it has not the same financial value and business impacts as that part. 

\paragraph*{Lobby}

The lobby is considered a major security risk. If there is a way to log in
without having access, the whole system and all it's information is at risk.
The finantial value is also high, since such a vulnerability might force the
system to be taken down in order to get fixed, and this will of course also
impact on the business.

\paragraph*{Presentation configuration files}
It could be costly if the presentation configuration files, because you will
have to reconfigure the settings used before.

\paragraph*{DPG system files}
It can be very costly to replace the broken system if such an error occurs. It's
also considered a major security issue if it's possible to break the system
infrastructure.

\clearpage

\subsection{Threat assessment}
\subsubsection{Identifying threats}
When it comes to identifying threats we differ between “threat source”, “threat
action” and “threat consequence”. 

\paragraph*{Threat source}
Natural threat sources like tsunami, earthquakes, wind, snow, or rain storm
could have an impact on the system. But we are not going to focus on those in
this risk evaluation. We are going to focus on human threat sources.

Human threat sources can be planned attacks on the application or an action
preformed accidentally. The online course page can be a target for hackers
seeking excitement or publicity, or hackers with a connection to rival
online courses. Hackers could in this context also be students looking for not
yet published solutions to compulsory exercises.

There is also a possibility of internal threat. Dissatisfied student assistants
with publisher access could be motivated to do some harm to the system.

We do not find it likely that this online course is a target for professional
criminals, velociraptors or terrorists.

\paragraph*{Threat action}
Threat actions are the actions triggered by the threat sources. We normally
have three different categories: Natural, Human Deliberate and Human
Accidental. Since we don't consider the natural sources an issue, we are left
with Human Deliberate and Human Accidental. Human deliberate is an important
issue, since the system is web based and therefore vulnerable to attacks from
the outside. The most important aspect of human accidental, is by comprising
their own access login by falling to a trap set by a human deliberate source.

\paragraph*{Threat consequences}
We will also consider the consequences of possible thread actions. The threat
table will show the results of our evalution of consequences.

\subsubsection{Building a threat table}
By using the information gathered, we create a threat table with Thread action
combined with threat consequence. We show this table after the next step:

\subsubsection{Creating a likelihood scale}
Next we consider each action, and the likelihood for them to occur. See figure
3.

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{LikelihoodScale.png}
\caption{Likelihood scale}
\label{fig:LikelihoodScale}
\end{figure}

\subsubsection{Rating each threat}
By combining the likelihood table with the treat action/treat consequence table,
we can rate each threat with a number, enabling us to rate threats.

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{ThreatActionThreatConsequence.png}
\caption{Threat action and its consequences}
\label{fig:ThreatActionThreatConsequence}
\end{figure}

\clearpage

\paragraph*{Explanation}
For choosing the threats, we combined known vulnerabilites found in part 2
with possible events that could compromize the system. The likelihood of each
threat is rated, the higher the number, the more likely it is. We assume that
the electrical facilities where the web server stands are good. Unauthorized
reading access to system information assets such as stacktraces with
information and accidental misuse of publisher access are the threats we
consider most likely. Electrical spikes, publisher access misuse and
unauthorized reading access to the system (access to the system without beeing
a user) are considered least likely.

\subsection{Vulnerability assessment}

The pattern has five steps:

\subsubsection{Collect threat information}
This was already done in the last pattern, and we will use the information
gathered there.
\subsubsection{Identify vulnerabilites}
Thanks to the static and manual analysis of the system in part 2, we were able
to find some vulnerabilities in the system, and these were our biggest concerns:

\begin{itemize}
  \item Cross site scripting: We found several occurences of cross site
  scripting.
  \item System information leak
  \item Log forging
  \item Unreleased resource
  \item Poor error handling
  \item Input validation mechanisms
  \item Sessions stealing (by using XSS)
  \item Denial of service
\end{itemize}

\subsubsection{Build a threat/vulnerability table}
By combining the threats with the vulnerabilites, we end up with a
threat/vulnerability table. We will show the table after the next step. 

\subsubsection{Make a severity scale}
We have built our scale by using the example vulnerability scale from table
6.16 in the Security Patterns book. See figure 5.

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{VulnerabilitySeverityScale.png}
\caption{Vulnerability severity scale}
\label{fig:VulnerabilitySeverityScale}
\end{figure}

\clearpage

\subsubsection{Rate each vulnerability}

By combining the severity scale with the threat/vulnerability table, we can
rate each vulnerability. See figure 6.

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{ThreatActionVulnerabilities.png}
\caption{Threat-Vulnerabilites table for information assets}
\label{fig:ThreatActionVulnerabilities}
\end{figure}

\paragraph*{Explanation}
We have evaluated that the vulnerabilites with the highest severity are those
caused by a malicious publisher. They can easily exploit the cross-site
scripting flaw, and they also can misuse the resource moving error. We have also
rated log forging high. We think the severity of reading the stacktraces in
itself is not the most severe, but attacks can use this information to make
more spesific attacks towards the system. Accidental misuse of publisher rights
are considered low severity, as it often makes the information less readable,
and does not expose the system. Empty catch blocks can make the system behave
strangely, but this is also low prioritized.

\clearpage

\subsection{Risk determination}

By using the tables from the previous patterns, and the equation

\begin{verbatim}
Risk(A) = Sum[Threat*Vulnerability](A) * Asset Value (A)

\end{verbatim}

.. we can create a prioritized risks of the assets.
\\
First we must find which threats are related to which assets.

\subsubsection{Course Resources}

\begin{itemize}
  \item Electrical spike in computer room (1) * Server man Joe trips over the power 
chord (2)
\item Electrical spike in computer room (1) * The power supplier fails to
deliver power to the system. (3)
\item Misuse of publisher access (accidentally) (4) * Pushing the wrong
buttons, so that information is not displayed, or information is displayed incorrectly. (2)
\end{itemize}

The equation is:

\begin{verbatim}
Risk(Course Resources) = (1*2+1*3+4*2)*3
Risk(Course Resources) = 39
\end{verbatim}

\subsubsection{Solutions to compulsory exersizes}

No threats found.

\begin{verbatim}
Risk(Solutions to compulsory exersizes) = 0
\end{verbatim}


\subsubsection{Presentation editor and resource management}

\begin{itemize}
  \item Misuse of publisher access (on purpose) (2) * Employee adding a
  cross-site vulnerability to gain access to administrator rights by stealing his session. (5)
  \item Misuse of publisher access (on purpose) (2) * Triggering a
  denial-of-service attack by moving folders outside of system folder. (5)  
\end{itemize}

\begin{verbatim}
Risk(Presentation editor) = (2*5+2*5)*2
Risk(Presentation editor) = 40
\end{verbatim}

\subsubsection{Lobby (Authentication)}

\begin{itemize}
  \item  Unauthorized access to the system (2) * Brute force attack on login (3)
\end{itemize}

\begin{verbatim}
Risk(Lobby (Authentication)) = (2*3)*4
Risk(Lobby (Authentication)) = 24
\end{verbatim}

\subsubsection{Presentation Configuration Files}

\begin{itemize}
  \item Electrical spike in computer room (1) * Joe the server maintenance guy
  trips over the power chord (2)
  \item Electrical spike in computer room (1) * The power supplier fails to
  deliver power to the system. (3)
\end{itemize}

\begin{verbatim}
Risk(Presentation Configuration Files) = (1*2+1*3)*3
Risk(Presentation Configuration Files) = 24
\end{verbatim}

\subsubsection{DPG System Files}

\begin{itemize}
  \item Bugs and errors (3) * Empty catch blocks (2)
  \item Unreleased resource (3) * Accessing the code where the input stream
  never gets closed multiple times (3)
  \item Log forging (3) * By choosing the right request parameters, malicious
  user might be able to forge logs with false entries (4)
\end{itemize}

\begin{verbatim}
Risk(DPG System Files) = (3*2+3*3+3*4)*5 
Risk(DPG System Files) = 135
\end{verbatim}

Lets add these findings in a sorted table:

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{PrioritizedRisks.png}
\caption{Prioritized risks for online course}
\label{fig:PrioritizedRisks}
\end{figure}

Now we create a table which we will use to change risk value to a word
understandable by everyone. We define 6 equal ranges from 1 to max, which is
135.

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{RiskTranslation.png}
\caption{Qualitiative risk translation}
\label{fig:RiskTranslation}
\end{figure}

We then add the two last tables together:

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{QualitiativeRisk.png}
\caption{Qualitative risks for museum assets}
\label{fig:QualitiativeRisk}
\end{figure}

As we can see from the figure 9, the DPG System Files are in our example of
highest risk. Compulsory exercise solutions are neglitable, as we didn't find
any threats related to them.

\clearpage

\section{Solving known problems}

In part 2, the static and manual analysis revealed that there were some
problems in the system. 

\subsection{Cross-site scripting}
This problem can be solved by proper validation of input, and encoding on
output. Here's an example of how proper validation should be done:

\begin{figure}[htb]
\centering
\includegraphics[width=1\textwidth]{inputValidation.png}
\caption{Proper input validation}
\label{fig:inputValidation}
\end{figure}

\subsection{System information leak and HTTP 500-error}
The system often prints a stacktrace when an error occurs, which reveales a lot
of information about the system. This is very easy to fix, as you just got
to disabling a stacktrace setting in the application server.

\subsection{Missing check for null parameter / J2EE Bad practices}
The problems reported are easily fixed by adding a null check, and making the
classes reported serializable, so it's usable for several JVMs.

\subsection{Log forging}
The solution to this problem is also documented in part 2, but the main idea is
to strip the input part of the log of $\setminus$n. They should remove the
debugging part of the logging when it's close to production.

\subsection{Unreleased resources}
By closing the InputStreams after they have been used, we avoid the unreleased
resource problem.

\subsection{Poor error handling}
In the empty catch blocks, at least throw a RunTimeException or something
simular, such that it's possible to see that something has gone wrong. Also
throw more spesific throws, and not the general Exception exception.

\subsection{Math.random for pseudo number generator}
For generation of ``unique'' presentation id's and similar, they use the
Math.random-method, which is a pseudo number generator. They should add some
entropy to make it real random, and they should also check that the number they
use are unique, such that the same id can't occur twice.

\subsection{Overwriting of pattern defaults}
The overwrite pattern defaults possibility is a flexible way to change content
to your exact needs, but as mentioned in part 2, this is a real security issue.
In order for this to work, we got to be certain that no unauthorized personel
can access this feature. If the feature remains unchanged, it will be a good
idea to use the CHECK POINT \cite{checkpoint} security pattern to be able to
reauthenticate the user when the feature is invoked. We also think it will be wise to consider
using some sort of logging or version control for these files, such that you
can always go back to a previous working file if something goes wrong.
\\
\\
If we decide to change the architecture of the feature, we must think of how we
can combine its flexibility with security. Unfortunately, we don't think this
is possible without defeating the purpose of the feature. One solution would be
to make a graphical presentation of the different parts in the file, but
because of the unique apperance of each file, we think this would not work.

\section{Other security patterns}

\subsection{Check point}

As mentioned earlier in the report, the CHECK POINT \cite{checkpoint} pattern
could be of interest in this system. This evaluation is based upon the fact that some features has a
higher system risk than others. The is especially important for the overwrite
pattern functionality, but it could also be of interest in the resource part.
The administrator role is also a place where this pattern can be used.
Deletion of presentations for examle, should require re-authentication.

\subsection{Validation pattern}

We came across a great pattern for input validation: INPUT VALIDATION \cite{inpvalpattern}, which
would be useful in order to make sure input validation is done properly. It has
some known uses for Java EE, Stinger\cite{stinger} is one of them. It might be
interesting to include this input validation mechanism to DPG.

\section{Conclusion}
We have done a risk management, in order to find where the risky business would
occur. We had to use a fictional (but realistic) scenario in order to proceed
with risk management, but we still think that many scenarios are similar, such
that this risk evaluation can looked at to determine risk in many variants of
DPG projects.

DPG has some serious issues regarding security, the cross-site scripting
possibility is not something you want to have in your system. We still think
that most issues regarding security in DPG are solvable, and most of them can
be solved with minimum efford. The security patterns would be the most costful
to implement, as it's a bigger process than just fixing a few lines of code.

\begin{thebibliography}{9}

\bibitem{design}
Berg, Karianne
\emph{Systemdesign for DPG 2.0}.
Department of Informatics, University of Bergen,
2008.

\bibitem{checkpoint}
Schumacher, Fernandez-Buglioni, Hybertson, Buschmann, Sommerlad,
\emph{Systemdesign for DPG 2.0}.
Security Patterns - Integrating Security and Systems Engineering
2006.



\bibitem{inpvalpattern}
Helge Netland, Yngve Espelid and Khalid Azim Mughal
\emph{Security Pattern for Input Validation}.
Department of Informatics, University of Bergen,
\begin{verbatim}
http://www.nowires.org/Papers-PDF/InputValidatorPattern.pdf
\end{verbatim}
2008.

\bibitem{stinger}
OWASP Stinger Project
\emph{Systemdesign for DPG 2.0}.
\begin{verbatim}
http://www.owasp.org/index.php/Category:OWASP_Stinger_Project,
\end{verbatim}
2006.

\end{thebibliography}

\end{document}